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REMARKS 

Recon$ideration of the present application is respectfully requested. Claim I has 
been amended. Claims 1 - 32 are currently pending. 

Rejections based on 35 U.S-C § 103 

Claims 1-32 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over 
Atkin, US. Publ. No. 2004/0181776 ("Atkin"). Applicants respectfully traverse the pending 
rejections. 

Claim 13-32 

Claims 13 - 32 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over 
Atkin. Applicants respectfully traverse this rejection because Atkin does not teach or suggest 
"an application interface component which prevents an application from handling said user input 
event by obfuscating said code from said application when one or more of said text converting 
components are interested in performing a conversion action " as required by independent claim 
25. Similarly, Atkin does not teach or suggest an input manager that is "configured to prevent 
one or more applications from handling said user input event by obfuscating said code from the 
one or more applications when said converting means are interested in performing a conversion 
action," as required by independent claims 13 and 30. 

Atkin discloses a system for providing Unicode support in legacy operating 
systems. Atkin, Abstract. Because legacy operating systems may not be equipped to handle a 
wide variety of languages, the system of Atkin includes an input method editor (IME) configured 
to convert an input into its Unicode value. An application that is Unicode capable can then 
receive the Unicode value corresponding to an input and can make use of the input. As 
explained by Atkin, "In this way 7 the operating system is bypassed so that the operating system 
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need not be equipped with an input method editor in order for Unicode to be used with a Unicode 
capable application." Atkin, para. 10. 

As previously mentioned, independent claims 13, 25 and 30 require preventing 
"an application from handling said user input event by obfuscating said code from said 
application when one or more of said text converting components are interested in performing a 
conversion action/* To teach this claim element, the Office Action relies on Atkin in the case 
where the target application is not Unicode capable. The Office Action states, "(Tin the case 
where the application does not support Unicode then an obfuscated version of the input is 
received by the application/' The Office Action explains, "This obfuscated version is simply the 
non-unicode input." 

Providing a non-Unicode input to an application does not teach or suggest the 
claim elements at issue for at least three different reasons. First, providing an application a non- 
Unicode input in no way teaches "obfuscating said code from said application." When an active 
application is not Unicode capable, Atkins takes no action with respect to a keyboard event and 
simply passes the event on for normal processing. Atkin, para. 37. Figure 6 illustrates this 
aspect- if the application does not support Unicode, the process ends without any further 
processing. As explained by Atkin, if the application i$ not capable of handling Unicode inputs, 
"the operation terminates with keyboard events being processed in a normal manner as if 
the [input method editor] were not present." Atkin, para. 37 (emphasis added). Accordingly, the 
providing of the non-Unicode input does not involve any obfuscation of a keyboard input. 
Rather, Atkin simply processes the input event "in a normal manner." If the claimed 
"obfuscating" of the code is to have any meaning at all, it must include some hiding of the 
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underlying value. Handling an input event in a normal manner in no way suggests "obfuscating' 1 
or hiding the input event's value from an application. 

Secondly, providing an application a non-Unicode input in no way teaches 
preventing "an application from handling said user input event." Atkin teaches a "bypass" in 
which an input method editor is provided to convert an input event into a Unicode value when a 
Unicode capable application is to receive the input event- Atkin, para. 31. If the application at 
issue is not Unicode capable, the bypass of Atkin is not utilized, and the system processes the 
event "in a normal manner." Atkin, para. 37. Importantly, the system of Atkins takes no action 
to prevent a non-Unicode capable application from processing the input event. If the application 
can handle the input event, then such handling will proceed as normal. In short, Atkins, by 
providing a non-Unicode value, in no way prevents "an application from handling" an event- 
Third, the claim elements at issue provide the obfuscated code t6 when one or more 
of said text converting components are interested in performing a conversion action." Atkin, 
however, provides a converted Unicode value when a converting component is interested in 
performing a conversion action- As explained by Atkin 7 "If the application 410 is capable of 
receiving Unicode input, the keyboard hook module 440 forwards the keyboard events to the 
keystroke conversion module 460." Atkin, para 37. The keystroke conversion module can then 
convert the keyboard event into its Unicode representation. Atkin, para. 39. Such a converted 
Unicode value, of course, is not an obfuscated code. So, in contrast to the claims, Atkins teaches 
providing a converted Unicode value when the conversion module is interested in performing a 
conversion action, not an obfuscated code as required by claims 13, 25 and 30. 

For at least these reasons, Atkin fails to teach or suggest preventing "an 
application from handling said user input event by obftiscating said code from said application 
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when one or more of said text converting components are interested in performing a conversion 
action," as required by independent claims 13, 25 and 30. Thus, Applicants respectfully submit 
independent claims 13, 25 and 30 are in condition for allowance. 

Applicants further submit that dependent claims 14-24, which depend from 
claim 13, are in condition for allowance for at least the same reasons discussed above with 
respect to claim 13. Applicants further submit that dependent claims 26 - 29, which depend from 
claim 25, are in condition for allowance for at least the same reasons discussed above with 
respect to claim 25, Applicants further submit that dependent claims 31 and 32, which depend 
from claim 30, are in condition for allowance for at least the same reasons discussed above with 
respect to claim 30. 

Claim 1 - 12 

Claims 1-12 stand rejected under 35 U.S.Q § 103(a) as being unpatentable over 
Atkin. Claim 1 has been amended. Applicants respectfully submit that Atkin does not teach or 
suggest "notifying an application of said input event by providing said application a sentinel 
value when the text converting component is interested in performing said conversion action/' as 
required by amended independent claim 1. 

Atkin has been previous discussed. In one aspect, Atkin teaches a "bypass" in 
which a converted Unicode value is communicated to a Unicode capable application, Atkin, 
para. 31. Alternately, when the active application is not Unicode capable, Atkins does not take 
any action with respect to a keyboard event and simply passes the event on for normal 
processing, Atkin, para. 37. In either case, Atkin in no way teaches or suggests utilizing a 
sentinel value to notify an application of an input event. 
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In contrast, independent claim 1, as amended, recites "notifying an application of 
said input event by providing said application a sentinel value when the text converting 
component is interested in performing said conversion action." Atkin teaches the providing of 
an unconverted input value or a converted Unicode value in response to an input event. Atkin 
does not teach notifying an application of an input event by providing a sentinel value. Thus, 
Applicants respectfully submit that independent claim 1 is in condition for allowance. Applicant 
further submits that dependent claims 2- 12, which depend from claim 1, are in condition for 
allowance for at least the same reasons discussed above with respect to claim 1. 

Conclusion 

For the reasons stated above, Claims 1 - 32 are in condition for allowance. If any 
issues remain which would prevent issuance of this application, the Examiner is urged to contact 
the undersigned prior to issuing a subsequent action- The Commissioner is hereby authorized to 
charge any additional amount required, or credit any overpayment, to Deposit Account No. 
19-2112. 

Respectfully submitted, 

Robert H. Reckers 
Reg. No. 54,633 



SHOOK, HARDY & BACON L.L.P. 
2555 Grand Boulevard 
Kansas City, Missouri 64108 
Phone: 816/474-6550 
Fax: 816-421^5547 
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